High Level Design
Common Area for High Level design documents
For those of you with XMI capable Design Editors I'll put the XML here
http://www.fourthought.com/projects/DigitalCreations/hld.xmi
Here is a link to the class diagram from the above XMI
http://www.fourthought.com/projects/DigitalCreations/hld.gif
General Design Discussions:
Last nights Use case analsys meeting drove a high level design. The XMLDocument implementation will be seperated into 2 focus areas.
- Importing an XML document into Zope as a single object. This new single object will overide the Element interface to allow traversal of childnodes, etc as if it where a tree of objects. Objects returned from get_childNodes will be transient (not persist in the Zope Database). The reasoning for this is to allow an XMLDocument to be used in all places a Zope tree (or DOM tree) can be used, but not pollute the Database with zillions of objects.
- Importing an XML document into a Zope tree. This will take an XML Document parse it, map it based on a user defined mapping from Elements/Attributes to Objects/Properties, and create Zope Objects based on the mapping. ALL INFORMATION IN the original XML document that is not mapped to a Zope Object or Property will not bew represented in the Zope Hierarchy. This option is inteded for import use cases only.
General Note: In all places where importing of an XML document is referenced, we will include, edit from scrathc, load file, and load URL.
General Note: When a Zope tree that contains XMLDocument Objects is serialized (A.K.A. pretty print) The XMLDocument Object will serialize into a seperate file, and the original file will contain a xlink replace atrtibute, ie the original file will reference a full XML file. This is because a valid XML file cannot contain another valid XML file.
Mike